Computer networks couple various types of computer systems in a manner that enables the network coupled computer systems to access data from a variety of sources of information. Some computer networks allow media content to be streamed from one or more network coupled sources of media content to one or more network coupled receivers of media content. In such computer networks, media content can be streamed by media content servers and played back by media content playback systems that are associated with the media content receivers. Conventional systems often use Hypertext Transfer Protocol (HTTP) and Transmission Control Protocol (TCP) to stream media across a network to media receivers.
As more and more devices are connected to networks, the ability to effectively use bandwidth becomes increasingly important for smooth playback. Some modern communication protocols, such as TCP, divide data into packets and guarantee that packets reach their destination in sequence. The receiving device sends acknowledgements of packets received and requests retransmission when packets are not received from the sending device. In order to reduce packet loss, communication protocols have flow control mechanisms that adjust, based on network congestion, how much data can be sent to a device each time data is sent. For example, TCP supports flow control though the concept of a window, which is the amount of outstanding (unacknowledged by the recipient) data a sender can send on a particular connection before it waits to receive an acknowledgment back from the receiver that it has received some of the data. After TCP has sent the amount of data corresponding to the window size, no more data is sent until the client transmits to the server an acknowledgment of received data, which is in the form of updated window information indicating that the client is ready to receive more data. As more and more packets are successfully received and acknowledged, TCP slowly increases the window size and thereby increases the amount of data sent in each transmission and thus increasing the bandwidth utilization.
When the amount of data transmitted exceeds the available network bandwidth, there is packet loss and requests for retransmission are sent to the sending device. Communications with flow control based on congestion respond to this by reducing the amount of data sent during each transmission. For example, any packet loss is assumed to be a result of network congestion by TCP and it responds by backing off, cutting the window size in half instead of continuing to send packets that will be lost. This sudden reduction in the TCP window is known as window collapse.
TCP responds this way whether the packet loss was caused by temporary fluctuations in bandwidth or by exceeding the available bandwidth. For example, as soon as a device tries to send more data than the network can reliably transmit there will be packet loss. The receiving device will then send requests for retransmission and TCP responds by backing off, significantly reducing the rate at which data is sent from the host If the rate at which data is sent is lower than the total network capacity, the remaining network bandwidth will remain unused until TCP slowly increases the window size again. Thus, TCP may dramatically and unnecessarily reduce how much effective throughput is available.
Sudden reductions in available bandwidth can negatively impact playback of streaming media. Playback devices typically have jitter or data buffers to allow playback to continue smoothly despite network issues such as connection interruptions or bandwidth changes. Before starting playback, a playback device will download sufficient data to fill the buffer so that playback can proceed smoothly. As the content in the buffer is played, the playback device makes subsequent requests to buffer the next portion of the content. A reduction in available bandwidth impacts the ability of a device to fill the buffer and thus the ability to provide smooth playback. For example, in the case of video streaming over a network to a device if the network throughput is suddenly cut in half by TCP, it may not be possible to refill the buffer fast enough to avoid being forced to halt playback.
Playback can further be impacted because flow control mechanisms may reduce the amount of data sent during transmissions following periods of non-communication from the receiver. In particular, this situation may occur if the last window raise request from the receiver is lost and the receiver does not send a new request for data. If the receiver is under heavy load and cannot process data as fast as the sender is sending it, the window size will decrease until it eventually gets to 0. When this happens, the sender is prevented from sending data until it receives a window update from the receiver with a non-zero window size. If that window update is lost, then the host could wait indefinitely. To prevent such an infinite wait, TCP implements a “persist timer” which, every 5-60 seconds, will fire off a zero window probe from the sender to the receiver. This 1- byte probe effectively queries the client for the actual size of the window, as the receiver will send its window size as part of the acknowledge for the probe. While this behavior works well for non-real-time networking scenarios, it works very poorly for real-time streaming. During the “persist timer” waiting period, the receiving device's buffer may deplete sufficiently such that the device is forced to halt playback. For example, if there is a five second buffer and no data is transmitted for five seconds due a lost window raise request, the device will run out of data to play and will starve, causing glitching and drop-outs.